feat(agent): show readiness and capabilities before delegation - #6643

Note: This is a replacement for PR #2957, which was accidentally closed when branches were force-pushed after a commit identity rewrite. The changes are identical, rebased onto the latest main.

Closes #2931.

What this fixes

Buzz currently makes an owner infer whether an agent is ready for local delegation by cross-referencing the agent editor, managed-runtime state, presence, and ACP observer logs. Missing evidence can look like unsupported behavior, while requested and effective permission modes are not visible together.

The important pre-delegation questions should be answerable in one place: is this local process healthy, which runtime and model are active, which features and tools were actually reported, how risky are those tools, and is the evidence from the current process and session?

What changes

The owner-only Runtime tab now includes a readiness and capability manifest built from four existing evidence sources:

• the ACP runtime catalog for installation, authentication, adapter, and static runtime facts;
• managed lifecycle state for the current process and community connection;
• current presence;
• the encrypted owner observer stream for ACP initialize, session configuration, commands, tools, model, protocol, and permission evidence.

The card shows installation, authentication, process, community, presence, observer readiness, runtime and model facts, prompt and output features, commands, MCP source names, tool descriptors and risk classes, requested and effective permission modes, evidence source, divergence, freshness, and known limitations.

The reducer treats absent or malformed evidence as unknown. Evidence is retained independently of the capped raw transcript, but it is invalidated across process and session boundaries. A stopped process, failed lifecycle, offline presence, closed observer, or initialize event from an older process cannot produce a ready state.

Trust boundary

This is local owner evidence, not a public capability, safety, or reputation claim. The UI says “Runtime ready” and identifies the owner-and-machine scope.

The harness projects only MCP server names and permission semantics. It does not forward MCP commands, arguments, environment values, credentials, executable paths, raw lifecycle errors, or config values.

Desktop parsing is strict and bounded. Older Desktop backends that do not report the new static fields remain compatible and render those facts as unknown. A non-owner E2E regression test verifies that neither the Runtime tab nor the manifest is exposed.

Verification

• Rebased onto current main at 5bf78671f45178f8de02ba18d3d321cbbf19cd1f; the current PR head is d53016c8490f1c0675b4dc56ac033bb7c9f29084.
• Resolved the permission conflict in favor of current main's auto-approval behavior while retaining the manifest's requested/effective permission evidence and corrected fallback wording.
• cargo test -p buzz-acp --lib passes 689 tests after removing an unrelated inherited BUZZ_ACP_LAZY_POOL environment override.
• The prior full branch verification passed Rust formatting and Clippy, Desktop/web checks and builds, Rust package tests, Desktop and Tauri suites, focused owner/non-owner Playwright coverage, and rendered-card inspection. Its one mobile failure reproduced identically on clean main and did not touch this PR's files.

Non-goals

• No public or portable capability attestation.
• No observation receipt, capability digest, or shareable claim envelope.
• No third-party reputation or protocol integration.
• No arbitrary wall-clock TTL; freshness is bound to the current healthy process, observer connection, session, presence, and community evidence.
• No automatic delegation or permission-policy change.
• No storage of secrets, full runtime configuration, or raw observer payloads.